In a service call or event processing, using a distributed software architecture, the transmission of messages may be either synchronous or asynchronous. The messages are distributed and multicast with full recipient isolation wherein each multicast message is processed independently from each other.
FIG. 1 shows a synchronous transmission of messages or service calls between two systems, on one side a calling system 110 and on the other side a remote system 120, wherein the calling system 110 controls the order of the message processing. In this case, the calling system 110 is waiting for the result of remote processing; as a consequence the caller is the master regarding the order in which messages are actually processed on a server system or the remote system.
A transmission 111 of a first message A from the calling system 110 is processed in the remote system 120 and followed by a message A processed 121 returned to the calling system 110. Once the message A processed is received, the calling system 110 can start a transmission 113 of a second message B to the remote system 120. The second message B is then processed in the remote system 120 and a message B processed 123 is returned to the calling system 110.
In this exemplary flow diagram, the chronological processing of the synchronous calls or messages between the calling system 110 and the remote system 120 shows that the process 112 of the first message A by the server system or the remote system 120 occurs before the process 114 of the second message B.
FIG. 2 shows an asynchronous transmission of messages or service calls between a calling system 210 and a server system or a remote system 220, wherein the calling system 210 sends a service call or message to the server system or a remote system 220 which will then processes the message based on its own scheduling. The client system or the calling system 210 is loosing control of the timing of the message processing.
A transmission 211 of a first message A from the calling system 210 is processed in the remote system 220. In the meantime, the calling system 210 has started a transmission 213 of a second message B to the remote system 220. The second message B is then processed in the remote system 220 and it cannot be determined whether a message B processed is returned to the calling system 210 before a message A processed.
In this exemplary flow diagram, the chronological processing of the asynchronous calls or messages between the calling system 210 and the remote system 220 shows that the process 212 of the first message A by the server system or the remote system 220 occurs more or less at the same time as the process 214 of the second message B. It would also be possible that the second message B is processed before the first message A, which could severely impact the relevancy of the sequence containing messages A and B.
FIG. 3 is an exemplary flow diagram showing a parallel processing of service calls or messages in a distributed system. In distributed systems, to comply with the resilience and scalability requirements, service calls or messages are processed in parallel by instantiation and/or in multithreading. In this figure, Instances 1, 2, 3, . . . , and n, referred as 310-1, 310-2, . . . and 310-n of the process system are processing four messages 1, 2, 3 and 4 in the message queue 340 with an inbound sequence.
Parallelized processes do not guarantee the order in which consecutive service calls or messages will be processed and finalized. However, service calls or message processes sometimes require strong enforcement of a sequence between correlated events or messages.
Therefore, message 2 is processed first, followed by message 1, then message 4 and finally message 3. This is an inconsistent transactional processing order.
In this figure, the sequence refers to the order in which the service calls or messages are to be conveyed and/or processed by the distributed system. This order is generally driven by the business process or an industry standard. By not respecting this order, the outcome results in inadequate processing and in the worst case in irreversible corruption of the stored functional data, also called database corruption.
FIG. 4 is an exemplary flow diagram showing a parallel processing of asynchronous calls or messages in a distributed process system which results in a risk of de-ordering the processing of messages and corrupted data.
In a synchronous environment, the sequencing is ensured by the emitter system or the calling system which initiates the messages to the remote system one after the other, controlling de facto the sequence flow between correlated messages.
This sequencing becomes impossible when the emitter system or the calling system 410 has to deal with asynchronous and distributed processes, as it is incapable to determine the end of the processing of a message on the remote system 420. FIG. 4 shows this risk where a transmission 411 of a first message A from the calling system 410 to the remote system 420 is followed by a transmission 413 of a second message B. The process 414 of the second message B starts before the process 412 of the process 414 of the first message A. Therefore, the message processing may be inversed, which results in inadequate processing and in the worst case in irreversible corruption of the stored functional data, or database corruption.
Therefore the present invention aims to mitigate the aforementioned problem and to avoid any irreversible corruption of the stored functional data, or any database corruption.